AD-A232  782 


.  _ _ _ _ 


1C  m  COr  r 


NPS55-90-22 


NAVAL  POSTGRADUATE  SCHOOL 

Monterey,  California 


DT1C 

ELECTEf 
MAR  15  199« 

B 


APPLICATION  OF  FUTURE  STATE  DECISION 
MAKING  IN  THE  EAGLE  COMBAT  MODEL 


SAMUEL  PARRY  and  ARTHUR  SCHOENSTADT 


September  1990 


Approved  for  public  release;  distribution  is  unlimited. 
Prepared  for: 

US  Army  TRADOC  Analysis  Command 
Fort  Leavenworth,  KS  66027 


) 

f*  5 


91 


11  055 


NAVAL  POSTGRADUATE  SCHOOL 
MONTEREY,  CALIFORNIA 


Rear  /  Imiral  R.  W.  West,  Jr.  Harrison  Shull 

Super  tendent  Provost 


This  report  was  prepared  for  and  funded  by  US  Army  TRADOC  Analysis 
Comm?” o  « 

This  report  was  prepared  by: 


Professor  of  Operations  Research 


Professor  of  Mathematics 


Reviewed  by:  Released  by: 


PETi  i<  PURDUE  Dean  of  Faculty  and  Graduate  Studies 

Professor  and  Chairman 
Department  of  Operations  Research 


Security  Classification  of  this  pace 


REPORT  DOCUMENTATION  PAGE 


la  Report  Security-  Classification  UNCLASSIFIED 


2a  Security  Classification  Authority 


2  b  Declassificatioa'Downgrading  Schedule 


4  Performing  Organization  Report  Numberfs)  NPS55-90-22 


6a  Name  of  Performing  Organization  6b  Office  Symbol 

Naval  Postgraduate  School  (if  Applicable)  OR 


6c  Address  (city,  state,  and  ZIP  code) 

Monterev,  CA  93943-5000 


8a  Name  of  Funding/Sponsorxng  Organization  8b  Office  Symbol 

US  Army  TRADOC  Analysis 
Command  OR 


8c  Address  (city,  slate,  and  zip  code)  Fort  Leavenworth,  KS 


1  b  Restrictive  Markings 


3  Distribution  Availability  of  Report 

Approved  for  public  release;  distribution  is  unlimited 


5  Monitoring  Organization  Report  Numberfs) 


7a  Name  of  Monitoring  Organization 

US  Army  TRADOC  Analysis  Command 


7  b  Address  (city,  state,  and  ZIP  code ) 

Fort  Leavenworth,  KS  66027 


9  Procurement  Instrument  Identification  Number 
(If  Applicable) 

MIFR  #M  186 1044 


1  0  Source  of  Funding  Numbers 


Proertm  Element  Number 


Work  Unit  Accession  No 


1 1  Title  (include  Security  Classification)  Application  of  Future  State  Decision  Making  in  the  EAGLE  Combat  Model 


12  Personal  Authors  Parrv,  Samuel  H.  and  Schoenstadt.  Arthur 


13a  Type  of  Report  1  3 b  lure  Covered  14  Date  of  Report  (year,  montk.day/  15  Page  Count 

Technical  From  To  1990,  September 


1 6  Supplementary  Notation  The  views  expressed  in  this  paper  are  those  of  the  author  and  do  not  reflect  the  official 
olicy  or  position  of  the  Department  of  Defense  or  the  U.S.  Government. 


1  7  Cosati  Codes  I  18  Subject  Terms  (continue  on  reverse  if  necessary  and  identify  by  block  number) 

Field  |  Group  ]  Subgroup  |  Airland  combat  simulation;  Generalized  Value  System;  GVS;  future  state 

decisionmaking;  EAGLE 


19  Abstract  (continue  on  reverse  if  necessary  and  identify  by  block  number 

EAGLE  is  a  systematic  combat  simulation  which  is  currently  under  development  by  the  TRADOC  Analysis 
Command  at  Fort  Leavenworth.  EAGLE  is  written  using  the  Artificial  Intelligence  (AI)  language  LISP,  which  is 
ideally  suited  for  describing  both  combat  missions  and  decisions  in  understandable,  natural-language  terms  w  ithin 
an  extremely  sophisticated  tactics  knowledge  base. 

Earlier  reports,  however,  have  asserted  that  systematic  combat  models  which  use  the  so-called  present-state 
decisionmaking  paradigm  have  a  fundamentally  flawed  decisionmaking  process.  This  report  investigates  the 
application  in  EAGLE  of  an  alternative,  future-state  decisionmaking  architecture,  called  the  Generalized  Value 
System  (GVS),  describes  the  general  changes  to  EAGLE  code  and  data  structures  necessary'  to  implement  this 
methodology,  and  presents  an  example  of  how  we  believe  this  methodology  would  execute  within  EAGLE. 


20  Distribution/Availability  of  Abstract 
JxJ  unclassificd/unlimitcd  same  as  report 


22a  Name  of  Responsible  Individual 

S.  H.  Parr 


DD  FORM  1473,  84  MAR 


21  Abstract  Security  Classification 

dtic  users  I  Unclassified 


22b  Telephone  (Include  Area  code)  22c  C 

(408)  646-2779  OR- 


83  APR  edition  may  be  used  until  exhausted  security  classification  of  this  page 

All  other  editions  arc  obsolete  Unclassified 


1 


Abstract 

EAGLE  is  a  systemic  combat  simulation  which  is  currently  under  development  by  the 
TRADOC  Analysis  Command  at  Fort  Leavenworth.  EAGLE  is  written  using  the  Aitificial 
Intellegence  ( AI)  language  LISP,  which  is  ideally  suited  for  describing  both  combat  missions 
and  decisions  in  understandable,  natural-language  terms  within  an  extremely  sophiticated 
tactics  knowledge  base. 

Earlier  reports,  however,  have  asserted  that  systemic  combat  models  which  use  the  so- 
called  present-state  decisionmaking  paradigm  have  a  fundamentally  flawed  decisionmaking 
process.  This  report  investigates  the  application  in  EAGLE  of  an  alternative,  future- 
state  decisionmaking  architecture,  called  Generalized  Value  System  (GvSj,  describes 
ttie  general  changes  to  EAGLE  code  and  data  structures  necessary  to  implement  this 
methodology,  and  presents  an  example  of  how  we  believe  this  methodology  would  execute 
within  EAGLE. 
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I.  Introduction 


Military  force  planners  must  continually  postulate  the  scenarios,  threats,  available 
systems,  political  and  economic  environments,  and  national  resolves  which  will  exist  at 
some  future  time.  Moreover,  these  planners  now  face  increasingly  tough  choices  with 
respect  to  how  best  commit  ever-scarcer  resources  to  procure  weapon  systems  and  develop 
force  structures  that  are  sufficiently  effective  to  deter  any  postulated  future  battles  from 
occurring. 

Combat  simulation  models  play  a  major  role  in  the  development  of  doctrine,  force 
structures  and  systems.  Several  widely  varying  general  approaches  to  the  modeling  of 
combat  have  been  studied  -  historical  curve  fitting  (e.g.  QJM.  [3]);  man-in-the-loop  (MITL ) 
models  (e.g.  JANUS,  [IS]);  systemic  (no  man-in-the-loop)  simulations  (e.g.  VIC.  [19]);  and 
analytic  models  (e.g.  COMAN,  [l] ).  Of  these  approaches,  systemic  and  MITL  models  are 
by  far  the  most  commonly  used  for  weapons  system  and  force  structure  analyses.  These 
two  approaches,  however,  are  not  interchangable.  and  numerous  tradeoffs  are  involved  in 
the  choice  between  a  systemic  or  an  MITL  model. 

MITL  models  are  generally  easier  to  set  up  and  run.  They  usually  require  far  less 
extensive  data  bases  and  can  use  far  simpler  programming  logic,  since  real  players  are 
able  to  react  and  make  decisions  in  unforseen  circumstances.  MITL  models,  however,  are 
not  well  suited  for  many  analytical  studies  because  their  results  are  generally  difficult  to 
replicate,  and  critical  command  and  control  decisions  usually  lack  clearly  defined  audit 
tr<ils.  Thus,  with  MITL  models,  the  contributions  to  the  overall  outcome  of  new  weapons 
systems,  force  structures  and  doctrines  becomes  almost  inseparable  from  the  dynamic  of 
the  individual  players,  the  “fog”  of  even  simulated  battle,  or  pure  luck.  (On  the  other 
hand,  most  current  systemic  models  require  frequent  stops  fo :  code  or  data  modifications 
and  subsequent  restarts  when,  according  to  the  judgement  of  analysts,  the  model  fails 
to  take  reasonable  or  realistic  military  actions.  Continually  having  to  implement  such  a 
stop/restart  sequence  effectively  turns  a  systemic  model  into  an  MITL  model,  and  usually 
a  very  inefficient  one  at  that.  Despite  this,  because  of  their  ability  to  conduct  controlled 
replications  and  produce  reasonable  audit  trails,  systemic  models  seem  likely  to  remain 
favored  for  most  analytical  studies.) 

In  an  earlier  report  [11].  we  developed  the  argument  that  a  fundamental  flaw  in  current 
systemic  combat  simulations  is  the  so-called  present-state  decisionmaking  paradigm.  In  this 
paradigm,  as  exemplified  by  the  Tactical  Decision  Rules  (TDR's)  or  decision  tables  of  \  IC. 
the  model  makes  tactical  decisions  by  examining  the  values  of  various  attributes  of  modeled 
entities  and  comparing  these  to  certain  (generally  multiple)  test  and  threshhold  values,  in 
what  is  effectively  little  more  than  “IF  ...  THEN”  constructs.  Our  position  in  [11]  was  that 
this  paradigm  is  flawed  in  that,  in  reality,  all  combat  decisions  above  the  level  of  simple 
battle  drill  are  made,  implicitly,  to  produce  some  desired  result,  not  at  the  present  time,  but 
somewhere  in  the  future.  The  correct  role  then,  of  the  present  state,  is  really  to  “trigger 
a  planning  process  and  act  as  of  a  set  of  initial  conditions  for  some  other  model  with  which 
the  future,  and  the  impact  of  various  alternative  actions  can  be  predicted.  Therefore, 
in  our  view,  the  flaw  with  current  decision  tables  is  that  the  analyst  who  developed  the 
table  almost  certainly  had  in  mind  some  predicted  future  that  should  occur  based  on  the 
present  state  as  reflected  in  tables,  but  this  model  exists  only  in  his  or  her  mind  and  is 
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therefore  neither  able  to  be  validated  nor  subject  to  the  establishment  of  audit  trails.  We 
have  further  proposed  an  alternate  future-state  architecture  for  decisionmaking  in  systemic 
models  as  part  of  the  Generalized,  Value  System  [GVS]  developed  during  the  ALARM  [4] 
project  at  the  Naval  Postgraduate  School.  Selected  aspects  of  the  GVS  will  be  outlined 
later  in  this  report. 

EAGLE  [17]  is  a  systemic  combat  simulation  which  is  currently  under  development 
by  the  TRADOC  Analysis  Command  at  Fort  Leavenworth  and  which  contains  several 
novel  and  significant  features.  First,  EAGLE  is  written  using  the  object-oriented  Artifi¬ 
cial  Intellegence  (AI)  language  LISP  [6].  Object-oriented  programming  is  widely  viewed 
as  premising  significant  improvements  in  programming  efficiency  through  class  structure 
inheritance  and  code  reuse.  LISP  processes  primarily  strings  of  characters  as  opposed  to 
numbers,  and  is  ideally  suited  for  describing  both  combat  missions  and  decisions  in  un¬ 
derstandable,  natural-language  terms.  In  EAGLE,  LISP's  AI  capability  has  allowed  the 
development  of  ait  extremely  sophiticated  tactics  knowledge  base  to  support  decisionmak¬ 
ing.  Furthermore,  EAGLE  is  the  first  model  we  are  aware  of  which  was  designed  from 
the  outset  to  essentially  mirror  the  doctrinal  Command  Estimate  process  [16]  of  military 
decisionmaking  as  taught  in  the  Command  and  General  Staff  Officer  Course. 

The  purpose  of  this  report  is  to  propose  a  GYS  future-state  prediction  methodology 
that  is  generally  compatible  with  the  EAGLE  architecture,  to  describe  the  general  changes 
to  EAGLE  code  and  data  structures  necessary  to  implement  this  methodology,  and  to 
outline  an  example  of  how  we  believe  this  methodology  would  execute  within  EAGLE. 

II.  Future-State  Decisionmaking  and  the  Generalized  Value  System 

As  we  indicated  above,  and  as  we  investigated  at  length  in  [11],  command  and  control 
decisionmaking  in  current  systemic  models  follows  what  we  have  called  the  present -state 
decisionmaking  paradigm.  That  is,  the  model  compares  the  values  of  various  modeled 
quantities  to  certain  (generally  multiple)  threshhold  values,  and  implements  a  decision 
based  on  what  is  effectively  an  "IF  ...  THEN”  construct.  We  hold  that  this  paradigm 
has  the  fundamental  weakness  that  only  the  current  values  of  the  attributes  are  tested 
against  the  decision  tables,  yet  these  values  should  properly  be  viewed  as  only  initial 
conditions  from  which  some  future  state(s)  will  evolve,  and  the  fundamental  reason  why 
the  model  is  supposed  to  trigger  a  decision  is  that,  in  the  judgement  of  the  analyst  who 
developed  the  table,  this  future  will  be  undesirable  unless  some  current  change  is  made. 
But,  with  decision  tables,  the  model  and  process  which  predicted  this  undesirable  future 
are  effectively  hidden,  and  really  exist  only  in  the  analyst  or  programmer's  mind. 

Given  what  we  believe  to  be  the  fundamentally  flawed  nature  of  the  present-state 
decisionmaking  model,  we  proposed  in  [11]  an  alternative  architecture  for  decisionmaking 
in  systemic  models.  This  proposed  architecture  blended  what  we  believe  are  the  basic 
elements  of  realistic  decisionmaking  -  the  current  situation  only  initiates  a  planning  pro¬ 
cess:  this  planning  process  includes  an  explicit  projection  of  the  anticipated  future:  and 
any  actions  are  initiated  solely  to  change  this  predicted  future  -  with  the  basic  limita¬ 
tions  of  current  computer  simulation  -  most  algorithms  must  be  reduced  to  quantitative 
computation.  In  our  proposal,  the  essential  elements  of  this  future-state  decisionmaking 
architecture,  which  we  referred  to  as  the  Generalized  Value  System,  were  postulated  to  be: 
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1.  For  each  model  entity,  an  explicitly  defined  state  vector,  consisting  of  quantifiable 
elements  which  the  model  is  capable  of  representing. 

2.  A  plan  or  mission.  This  will  be  essentially  a  set  of  time,  distance  and  force- 
oriented  constraints  which  a  given  model  decisionmaker  will  try  to  satisfy. 

3.  A  set  of  explicit  algorithms  which  can  produce  predicted  future  states  of  any 
given  entity,  given  a  present  state. 

4.  A  set  of  algorithms  for  deriving  a  quantitative  measure  (or  measures)  of  the  value 
of  any  entity,  given  the  state  of  that  entity.  These  algorithms  must  include  the 
time  discounting  of  value  proposed  in  [10]. 

5.  A  set  of  algorithms  for  converting  a  plan  or  mission  and  a  set  of  current  and 
future  values  into  decisions. 

Before  continuing,  we  would  make  one  additional  point  regarding  future-state  predic¬ 
tion  in  combat  models.  This  point  is  that  there  are  really  four  fundamental,  and  to  some 
degree  independent,  questions  that  any  command  and  control  process  must  address.  (In¬ 
terestingly  enough,  these  bear  some  similarities  to  certain  classic  problems  in  mathematics, 
although  at  this  time  we  see  no  clearly  exploitable  advantage  in  recognizing  this  relation.) 

1.  What  procedure,  algorithm  or  test  determines  whether  a  particular  course  of 
action  will  (or  perhaps  more  appropriately  should )  accomplish  the  mission?  This 
question  is  very  much  like  the  question  of  how  does  one  mathematically  verify 
that  a  proposed  solution  to  a  problem  is  valid. 

2.  Is  there  a  feasible  course  of  action  which  will  still  accomplish  the  mission?  This 
question  is  akin  to  the  mathematical  question  of  existence  of  solutions  (which  can 
often  be  answered  in  the  affirmative  even  when  a  solution  cannot  be  produced). 

3.  If  there  are  any  feasible  courses  of  action,  is  there  one  which  is.  under  some  mea¬ 
sure.  optimal?  This  issue  is  similar  to  the  mathematical  question  of  uniqueness  of 
solutions  (which,  again  interestingly,  can  often  be  answered  even  when  no  solution 
has  been  produced). 

4.  How  can  one  construct  feasible  courses  of  action,  given  that  they  exist? 

As  we  proceed  in  this  report,  we  shall  comment  on  the  degree  to  which  proposed  structures 
and  algorithms  can  answer  each  of  these  questions. 

As  we  emphasized  in  [11],  future-state  decisionmaking  and  the  GVS  are  really  only 
an  architecture  -  a  philosophy  of  how  to  more  accurately  model  combat  decisions  -  not 
any  one  particular  set  of  algorithms.  As  we  pointed  there,  several  of  elements  of  the 
GVS  architecture  were  independent  of  each  other,  and  could  be  implemented  with  more 
than  one  particular  algorithm.  The  primary  purpose  of  this  report  is  to  demonstrate  the 
application  of  this  architecture  to  the  development  of  specific  algorithms  for  a  model  now 
under  development  -  EAGLE. 

III.  The  EAGLE  Model 

As  we  alluded  to  in  the  introduction.  EAGLE  [17]  is  a  new  developmental  model 
with  several  unique  and  intriguing  features.  A  complete  description  of  ;dl  these  features 
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is  far  beyond  the  scope  of  this  report.  (Full  details  are  available  to  appropriate  agencies 
from  TRADOC  Analysis  Command.  Fort  Leavenworth.)  Nevertheless,  there  are  a  few  of 
these  features  that  are  especailly  noteworthy  because  of  their  relationship  to  command  and 
control  modeling.  The  first  is  that  EAGLE  is  written  in  LISP  [6],  a  language  originally 
developed  for  Artificial  Intelligence  research.  LISP  is  an  especially  attractive  language 
for  command  and  control  simulations,  since  it  was  designed  from  the  outset  to  be  used 
for  simulating  decisions.  Virtually  ail  other  languages  available  today,  including  ADA. 
lack  this  feature,  and  generally  model  command  and  control  only  with  varying  degrees  of 
awkwardness.  LISP  is  also  fairly  unique  in  that  it  operates  primarily  not  on  numbers,  but 
on  lists.  Numbers  may  be  included  in  these  lists,  but  more  commonly  the  lists  are  made  up 
of  strings  of  characters.  Thus,  a  LISP  model  can  make  tactical  decisions  based  on  model- 
stated  criteria  such  as  “receiving- heavy-incoming-fire."  This  feature  provides  both  almost 
immediately  self-documenting  code,  and  a  degree  of  visibility  and  comprehensibility  not 
offered  by  TDR’s  or  other  current  model  constructs.  Furthermoie.  LISP  also  encompasses 
very  highly  structured  knowledge  bases  (KB's)  in  which  not  only  can  command  and  control 
decision  logic  be  deposited,  but  from  which  such  logic  can  also  be  easily  recovered  and 
easily  modified.  Lastly,  current  versions  of  LISP  are  object-oriented.  Object-oriented 
programming  generally  allows  for  much  more  robust  data  structures,  since  objects  can 
be  ogranized  into  hierarchies  with  lower-ranked  objects  automatically  inheriting  elements 
from  objects  higher  in  the  structure.  Thus  a  change  to  the  data  structure  for  a  “parent" 
can  be  automatically  passed  on  to  all  of  the  “children,"  without  the  need  to  modify  any 
code  other  than  on  the  parent.  (By  contrast,  changing  a  single  calling  arguments  string  in  a 
FORTRAN  subroutine  can  require  changes  to  massive  numbers  of  other,  related  programs. ) 
This  object-oriented  structure  again  seems  especially  well  suited  for  simulating  combat, 
since  most  military  entities  belong  to  very  well-structured  hierarchies. 

The  EAGLE  model  has  another  very  appealing  feature,  apart  from  its  LISP-based 
structure.  It  is  the  first  combat  model,  to  our  knowledge,  designed  from  the  outset  to 
incorporate  fundamental  elements  of  the  doctrinal  Command  Estimate  decisionmaking 
process  [16]  as  taught  to  and  used  by  Army  officers  during  Fort  Leavenworth's  Command 
and  General  Staff  Officer  Course.  Major  elements  of  this  process  are  found  in  the  exten¬ 
sive  and  sophisticated  preprocessor  being  developed  as  part  of  the  EAGLE  project.  This 
preprocessor  is  menu-driven  and  integrated  with  a  terrain  IvB.  Using  the  preprocessor,  an 
analyst  can  rapidly  develop  a  tactical  scenario  in  the  same  sequence  as  the  Command  Es¬ 
timate  process.  The  menus  allow  formulation  of  complete  sets  of  plans  and  orders  for  each 
subordinate  unit,  and,  if  necessary,  a  set  of  tailored  tactical  decision  rules  appropriate  for 
each  plan.  Furthermore,  each  plan  is  broken  into  clearly  identified  phases,  with  potential 
critical  events  also  identified  within  each  phase.  Lastly,  each  phase  of  a  subordinate  unit's 
plan  also  is  clearly  linked  to  a  phase  of  that  subordinate’s  command  headquarters'  plan. 
(Normally,  of  course,  each  phase  of  a  command  headquarters  plan  will  encompass  several 
phases  or  tasks  for  a  subordinate.) 

Actually.  EAGLE  recognizes  two  basic  types  of  “units"  in  the  above  context.  The  first 
type  is  called  a  resolution  unit..  A  resolution  unit  is  both  the  smallest  level  tactical  unit 
played  in  the  model,  and  the  only  ground  maneuver  entity  in  the  model  "rhich  engages  in 
combat  activity.  A  command,  or  headquarters  unit,- by  contrast,  is  purely  a  planning  ac- 
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tivity,  and  may  have  as  subordinates  either  other  command  units,  or  resolution  units.  (An 
actual  command  headquarters,  e.g.  a  brigade  HKC.  has  dual  representation  -  a  command 
unit  object  which  represents  the  planning  functions,  and  a  resolution  unit  which  models 
the  physical  functions,  such  as  movement  of  the  command  post.)  These  two  object  types 
are  also  treated  differently  in  terms  EAGLE's  mission  planning  structure  (albeit  these 
differences  often  seem  subtle  and  to  involve  more  definitions  than  substance). 

The  overall  structure  of  the  model  decisionmaking  architecture  in  EAGLE  starts  with 
a  defined  plan  (generally  prepared  using  the  preprocessor).  A  plan  consists  of  a  sequence 
(list )  of  phases,  each  associated  with  a  unique  order.  Each  ord<  r  is  then  another  sequence  or 
list,  each  element  of  which  contains,  as  a  minimum,  a  task,  an  objective,  and  information  on 
when  or  under  what  conditions  that  task  would  start  and  end.  (Curiously,  there  is  no  slot  in 
the  task  list  for  the  enemy  force,  if  any,  to  be  defeated,  or  of  any  degree  of  destruction  to  be 
inflicted  on  the  enemy.  This  is  certainly  less  than  fully  realistic,  and  does  have  implications 
for  any  future-state  prediction  processes.)  Resolution  units  then  carry  out  these  orders 
through  a  sequence  of  operational  activities.  Figure  1  displays  some  of  the  common 
phases  and  tasks  that  may  comprise  a  plan,  and  the  operational  activities  allowable  for 
a  ground  maneuver  unit.  Although  the  conceptual  structure  of  EAGLE  allows  phases  to 
start  and  end  at  specific  times,  the  current  model  in  fact  changes  phases  under  only  one  of 
two  criteria  -  on-order  (i.e.  when  directed  by  higher)  or  on-own- initiative.  Thus  a  critical 
aspect  of  each  phase  is  the  transition  rules,  which  are  contained  in  the  KB.  that  signal  the 
need  to  start  the  next  phase.  For  resolution  units,  these  rules  determine  whether  a  change 
in  phase  is  warranted  by  examining  various  attributes  which  the  mode!  documentation 
refers  to  under  the  general  heading  of  the  unit's  self  objective  status  or  self  decision  factors. 
(Like  almost  all  LISP  constructs.  ft>e<=e  attribute  will  be  string  '’allies  and  the  associated 
rules  string-based.  In  other  words,  th«  rule  for  breaking  contact  may  consist  of  the  unit's 
objective  status  being  determined  to  be  ‘breaking-contact-receiving-hvy-losses.')  While  on 
order  rules  axe  clearly  required  in  order  to  effect  synchronization  of  the  various  phases  of 
the  plan,  the  uncertainly  of  when  they  will  "fire'"  does  significantly  complicate  the  future- 
state  prediction  problem.  Furthermore,  including  time-dictaied  transition®  ir  any  given 
plan  will  virtually  force  some  kind  of  future-state  prediction,  since  the  amount  of  combat 
power  sufficient  to  accomplish  a  mission  with  no  time  constraints  may  be  insufficient  when 
time  constraits  are  added.  Lastly,  in  any  event,  the  current  on-order  transition  rules 
should  be  enriched  to  address  such  essentially  future-state  issues  as  whether  requiring  one 
subordinate  resolution  unit  to  assume  a  hasty  defense  prior  to  starting  the  next  phase 
of  its  plan,  while  another  completes  its  part  of  the  current  phase,  will  result  in  sufficient 
additional  losses  that  the  first  unit  then  becomes  ineffective  to  perform  its  next  task?  (We 
refer  to  this  last  question  as  the  slack  time  issue,  and  shall  wherever  possible,  address  it 
and  the  other  issues  raised  above  in  this  report,  although  full  consideration  of  the  scope 
of  some  of  them  is  far  beyond  what  we  will  be  able  to  cover.) 

IV.  The  GVS/EAGLE  Test  Bed  Scenario 

In  order  to  demonstrate  the  algorithms  and  data  structure  necessary  to  incorporate 
the  GYS  future  state  decisionmaking  architecture  into  EAGLE,  we  shall  use  a  single,  very 
representative  scenario.  (This  approach  is  similar  to  that  we  used  to  demonstrate  the  proof 
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Selected  Blue  Phases 

Main-atk-conduct-passage-of-lines  (bde/div ) 
Conduct-spt-atk-through-feba-bn  (bde/div ) 
Conduct-spt-atk-through-feba-reg  (bde/div) 
Main- atk-penet rate- feba-bns  (bde/div) 
Main-atk-attack-2nd-ech-feba-reg  (bde/div) 
Hasty-Defcnd-in-place 
Main-atk-attack-2ech-feba-div  (bde/div ) 
Main-atk-attack-2ech-reg-feba-div  (bde/div ) 
Main-atk-attack-rear-feba-reg  (bde/div) 
Follow  (bde) 

Conduct -spt-atk-feba-reg  ( div ) 
Main-atk-penetrate-feba-reg  ( div ) 
Main-atk-penetrate-2ecli-feba-div  ( div ) 

Blue  Tasks 
Attack 
Defend 
Deploy 
Delay 
Marshal 
Follow 

Blue  Operational  Activities 
Traveling-Overwatch 
Bounding-  Overwatch 
Break-Contact 
Defeat 

Defend-Assembly-  Area 
Defend-Battle-Psn 
Defend- Hasty- Bat  tle-Psn 
Delay 

Occupy- Assembly- Area 
Occupv-Battle-Position 


Figure  1  EAGLE  Phases.  Tasks  and  Operational  Activities 

of  the  basic  GVS  concept  in  VIC  [12].)  The  basic  elements  of  this  scenario  are 
portrayed  in  Figure  2. 

In  this  scenario,  a  Blue  brigade,  consisting  of  two  mechanized  task  forces 
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Figure  2  -  The  Basic  Scenario 


task  force  and  an  attack  helicopter  battalion  has  been  tasked  to  penetrate  an  attrited 
defending  Red  motorized  rifle  regiment  with  which  the  brigade  is  already  in  contact.  The 
Red  regiment  is  in  a  hasty  defense  with  its  two  remaining  motorized  rifle  battalions  on 
line  in  its  first  echelon,  and  its  tank  battalion  situated  in  an  assembly  area  for  use  as  a 
counterattack  force.  In  addition,  but  clearly  important  for  the  Blue  commander’s  planning, 
a  Red  tank  regiment  (probably  from  the  same  division  as  the  defending  motorized  rifle 
regiment  and  probably  with  the  mission  of  division-level  counterattack)  is  situated  outside 
the  brigade's  area  of  operations.  We  assume  the  blue  commander’s  general  plan  will 
be  to  attack  with  the  two  mechanized  task  forces  abreast,  to  sieze  objectives  A  and  B 
respectively,  then  pass  the  armor  tasK  force  through  to  sieze  objective  C  while  the  two 
mechanized  task  forces  consolidate  their  objectives.  Upon  securing  objective  C,  the  armor 
task  force  will  consolidate  that  objective  while  some  unspecified  (for  this  example)  following 
brigade  passes  through  to  exploit  the  attack.  The  attack  helicopter  battalion  is  in  reserve. 
Mobility  corridors  are  indicated  by  the  solid  lines  connecting  units  and  objectives. 

hi  terms  of  the  EAGLE  structure,  we  postulate  the  brigade  is  part  of  a  division 
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Division  Tasks  -  Blue-Main-atk-penetrate-feba-reg 

-  Blue- Main- at k-penei rate- 2ech-feba-div 

-  Blue-Hasty-Defend-in-place 


Figure  3  -  Phases  of  the  Division  Plan 


Division  Phase  -  Blue-Main-atk-penetrate-feba-reg 

Brigade  Phases  -  Main-atk-penetrate-feba-bns 

-  Main-at  k-at  tack-2nd-ech-feba-reg 

-  Hasty -Defend- in-place 

Division  Phase  -  Blue-Main-atk-penetrate-2ech-feba-div 
Brigade  Phases  -  Hastv-Defend-in-place 

Division  Phase  -  Blue- Hastv-Defend-in-place 
Brigade  Phases  -  Preparc-for-attack 


Figure  4  -  Phases  of  the  Brigade  Plan 


plan/order  that  consists  of  the  tasks  shown  in  Figure  3.  As  we  discussed  above,  this 
division  plan  then  will  create  a  brigade  plan/order  consisting  of  one  or  more  phases  for 
each  phase  of  the  division  plan.  as.  for  example,  shown  in  Figure  4.  Lastly,  the  brigade 
will  then  convert  each  phase  order  it  has  received  from  the  division  into  one  or  more  tasks 
for  each  subordinate  unit.  as.  for  example,  is  shown  in  Figure  5. 

In  an  actual  operation  each  level  of  command  is  assigned  an  area  of  operations  (AO). 
The  AO  includes  an  actual  physical  libox"  on  the  ground,  as  is  shown  for  the  brigade  in  Fig¬ 
ure  2.  By  doctrine,  each  commander  is  responsible  for  everything  that  happens  in  his  At), 
and.  subject  to  whatever  rules  of  engagement  apply,  has  the  authority  to  attack  all  enemy 
assets  in  his  AO  with  whatever  means  may  be  appropri  ite.  Thus,  as  Figure  2  indicates,  a 
unit  s  AO  must  encompass  not  only  territory  on  the  enemy  side  of  the  FLOT,  but  on  the 
friendly  side  back  to  that  unit's  rear  boundary.  When  command  headquarters  plan,  t [un¬ 
commonly  assign  subareas  of  their  assigned  AO  to  their  subordinates.  Thus,  for  example. 
Figure  G  shows  the  brigade  subdividing  a  portion  of  its  AO  into  two  battalion-sized  AO's 
and  then  assigning  each  of  these  to  one  of  the  lead  attacking  battalions. 

Also  by  doctrine,  each  level  of  command  has  an  area  of  interest  (AOI).  In  contrast 
to  the  AO  however,  the  AOI  is  not  necessarily  a  physical  area  on  the  ground  and  is  not 
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Division  Phase  -  Blue-Main-atk-penctrate-feba-reg 

Brigade  Phase  -  Main-atk-penetrate-feba-bns 
TF  1/92  Tasks  -  attack 

-  defend 
TF  3/SO  Tasks  -  attack 

-  defend 
TF  3/5  Tasks  -  follow 
Atk  Hel  Tasks  -  marshal 

Brigade  Phase  -  Main-atk-attack-2nd-ech-feba-reg 
TF  1/92  Tasks  -  defend 
TF  3/SO  Tasks  -  defend 
TF  3/5  Tasks  -  deploy 

-  attack 

-  defend 

Atk  Hel  Tasks  -  marshal 

Brigade  Phase  -  Hasty-Defend-in-place 
TF  1/92  Tasks'- defend 
TF  3/SO  Tasks  -  defend 
TF  3/5  Tasks  -  defend 
Atk  Hel  Tasks  -  marshal 

Division  Phase  -  Blue-Main-atk-penetrate-2ech-feba-div 
Brigade  Phase  -  Hasty-Defend-in-place 
TF  1/92  Tasks'- defend 
TF  3/SO  Tasks  -  defend 
TF  3/5  Tasks  -  defend 
Atk  Hel  Tasks  -  marshal 

Division  Phase  -  Blue-Hasty-Defend-in-place 
Brigade  Phase  -  Prepare-for-attack 
TF  1/92  Tasks  -  marshal 
TF  3/SO  Tasks  -  marshal 
TF  3/5  Tasks  -  marshal 
Atk  Hel  Tasks  -  marshal 


Figure  5  -  Resolution  Unit  Tasks  in  tin1  Brigade  Plan 

assigned  by  higher  headquarters.  Rather,  the  AOI  really  represents  that  time  honzov  out 
to  which  a  commander  must  be  looking  in  order  to  effect  ivelv  react  to  unforseen  events 
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Figure  G  -  Areas  of  Operation  for  the  Basic  Scenario 


or  counter  unexpected  threats.  While  there  are  suggested  doctrinal  times  associated  with 
the  AOI  at  each  level  of  command,  determination  of  each  unit's  AOI  is  up  to  that  unit's 
commander  and  depends  primarily  on  the  length  of  that  headquarters'  decision  cycle. 
The  AOI  will  normally  contain  not  only  the  unit’s  AO,  but  also  appropriate  portions  of 
higher  and  adjacent  units'  AO's.  The  AOI  plays  a  pivotal  role  in  the  GVS  architecture. 
In  GVS.  the  combat  power  of  assets  which  are  not  available  for  employment  at  the  present 
time  are  exponentially  discounted  depending  on  the  time  interval  until  they  will  become 
available  [10],  and  the  "time  constant’’  used  to  normalize  this  discounting  is  determined 
by  requiring  that  any  asset  at  the  outer  boundary  of  the  AOI  have  only  a  nominal  frac¬ 
tion  (5%)  of  its  full  power.  Figure  7  displays  both  the  brigade's  and  one  battalion's  AOI's 
superimposed  over  the  respective  AO's,  assuming  the  appropriate  time  horizons  are  three 
hours  for  the  brigade  and  one  hour  for  the  battalion.  (Vote  that  the  AOI  used  in  this 
context  should  not  be  confused  with  what  doctrinally  referred  to  as  a  named  area  of  inter¬ 
est  (NAI).  An  NAI  is  some  specific  limited  area  on  the  ground  where  a  commander  may 
focus  intelligence  collection  assets,  e.g.  to  discern  enemy  movements.) 
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Figure  7  -  Areas  of  Interest  for  the  Basic  Scenario 


Although  we  shall  not  be  able  to  develop  this  theme  fully  in  this  report,  another  key 
concept  from  ALARM  which  we  believe  may  be  exploitable  in  developing  a  future-state 
prediction  capability  for  EAGLE  is  that  of  the  time  domain  networks  (TDX).  A  TDX 
is  effectively  simply  a  PERT  or  CPM  network  representation  of  a  plan.  The  nodes  of  a 
TDN  represent  critical  events  in  the  plan  and  the  arcs  represent  the  phases  or  operational 
activities  necessary  to  progress  through  the  plan.  Such  networks  are  integral  parts  of  Soviet 
planning  [8],  where  they  are  used  to  automate  the  process  of  predicting  combat  outcomes. 
(The  analogous  process,  when  done  by  a  U.  S.  G3  is  called  “war  gaming  a  course  or  action." ) 
Conceptually,  creation  of  such  a  TDN  for  each  plan  in  EAGLE  should  be  relatively  simple, 
given  the  already  existing  plans  and  orders  structure.  Figure  S  displays  such  a  TDN  for 
our  sample  scenario.  Actually,  the  network  in  Figure  S  is  slightly  ambiguous  in  that, 
without  reference  to  the  phase  transition  rules  for  this  order  in  the  EAGLE  Tactics  KB. 
it  is  not  clear  whether  both  mechanized  task  forces,  or  only  one.  would  have  to  reach 
their  objectives  before  the  armor  task  force  can  deploy.  (For  our  scenario,  we  shall  assume 
that  both  mechanized  task  forces  must  reach  their  objectives  prior  to  deployment  of  the 
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armor  task  force.)  In  general,  we  expect  that  all  on-order  TDN  transitions  could  be 
reduced  to  simple  ‘'and"  or  “or"  combinations  of  completions  of  the  preceeding  arcs,  or 
such  combinations  plus  a  specified  time  in  the  network  having  passed. 


V.  The  GVS  Process  for  EAGLE 

In  this  section,  we  provide  a  step-by-step  outline  of  our  proposed  implementation  of  the 
GVS  into  EAGLE.  Where  known,  specific  EAGLE/LISP/KEE  notation  is  used.  In  order 
to  demonstrate  the  steps,  the  scenario  presented  in  the  previous  section  will  be  assumed. 
While  our  focus  for  this  example  is  a  brigade  and  its  associated  battalion  resolution  units, 
adding  echelons  above  the  brigade  level  should  follow  similar  logic.  The  primary  differences 
when  higher  echelons  (e.g.  divisions  or  corps)  are  added  will  be  longer  planning  horizons 
and  a  broader  spectrum  of  assets  to  be  considered  in  the  alternatives. 

The  GVS  process  described  below  should  be  performed  at  a  every  change  of  phase 
within  a  plan,  irrespective  of  the  unit  level,  and  thereafter  at  a  regular  time  interval,  de¬ 
pending  on  the  unit.  We  initially  recommend  that  the  resolution  units  be  reforecastcd 
every  30  minutes,  brigades  every  60  minutes,  divisions  every  120  minutes,  and  corps  ev¬ 
ery  240  minutes.  (Similar  times  should  be  utilized  when  GVS  prediction  is  implemented 
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for  the  RED  Units).  Our  initial  proposal  will  address  the  Blue  forecast  only.  The  principal 
steps  in  this  process  are  described  below. 

Step  1  -  As  each  plan  is  prepared  for  each  unit  in  the  preprocessor,  an  Area 
of  Interest  associated  with  that  plan  must  be  generated. 

The  AOI  may  be  a  geometric  area  (assumed  to  have  piecewise  linear  boundaries)  or  a  time 
horizon.  A  slot,  e.g.  a-gvs-area-interest-(unit  designation),  which  points  to  the  AOI, 
must  be  created  as  part  of  the  plan.  The  two  characteristics  required  of  the  AOI  are: 

a.  It  must  be  large  enough  (in  both  the  time  and  space  domain)  to  fore''»«f  to  the 
end  of  the  objective  of  the  Plan. 

b.  It  must  relate  to  each  “terrain  analysis"  area  currently  done  in  the  preprocessor. 

(As  discussed  earlier,  it  might  prove  quite  useful  for  the  preprocessor  to  also  generate  a 
time  domain  network  for  each  plan.  This  TDX  could  be  stored  as  a  linked  list  structure 
equivalent  to  Figure  S.  Developing  the  necessary  code  to  generate  this  TDX  from  an  EA¬ 
GLE  plan  may  be  a  non-trivial  endeavor,  especially  as  regards  the  conversion  of  EAGLE 
transition  rules  to  network  activity  start/stop  conditions.  Xevertheless.  as  we  shall  point 
out  later,  having  such  a  network  available,  along  with  the  necessary  references  to  associ¬ 
ated  ground  coordinate,  e.g.  objectives,  offers  an  alternative  mechanism  for  future  state 
prediction,  and  is  a  potentially  fruitful  area  for  further  research.) 

For  our  subsequent  discussion,  we  assume  that  we  can  access  the  AOI  for  the  each 
plan.  We  also  assume  that  a  routine  will  be  available  which  can  test  whether  or  not  a  given 
location  is  in  some  specified  unit’s  AOI.  although  calls  to  this  routine  will  occur  later  in 
the  process. 

Step  2  -  Each  unit  should  have  two  slots,  one  corresponding  to  a  list  of  the 
“’tail  numbers”  of  each  friendly  unit  in  the  AOI  and  the  other  corresponding  to  a 
list  of  the  perceived  tail  numbers  of  all  enemy  units  known  to  the  unit. 

The  friendly  units  would  include  all  organic  assets  plus  any  Artillery,  ADA,  Fixed-Wing. 
Engineer,  Logistics,  etc.  units  attached  or  OPCOX  to  the  unit  being  considered.  With 
slight  modifications,  the  current  a-local-sitmap-friendly  slot  of  the  perceptions  ob¬ 
ject  in  the  Characteristics-KB  could  be  used  for  this.  In  our  example,  only  ground  ma¬ 
neuver  units  (defined  as  including  helicopter  assets)  will  be  considered.  The  list  of  en¬ 
emy  units  could  be  stored  in  either  the  (modified)  a-local-sitmap-enemy  slot  of  the 
same  object,  or  in  the  (modified)  a-prioritized-opponents  slot  of  the  res-decision- 
factors  object  of  the  same  KB.  Enemy  units  would  be  added  to  this  list  from  two  sources: 

a.  Those  within  the  visible  detection  (currently  4I\)  circle  of  each  resolution  unit. 
Some  code  modification  would  be  required  to  ensure  these  are  passed  "up  the 
line”  to  the  resolution  unit's  command  headquarters. 

b.  Those  that  are  detected  through  the  IXTEL/FUSIOX  process  which  currently 
produces  target  to  Headquarters  Units  and  to  the  Artillery  FSE.  Again,  some  code 
changes  would  be  required  here,  e.g.  to  include  passing  appropriate  information 
up  and  down  the  line. 
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The  modifications  to  the  detection  list  data  structure  should  ensure  that  each  detected 
enemy  unit  in  the  AOI  has  not  only  a  tail  number,  but  a  location,  a  direction  and  speed 
of  movement,  and  a  last  time  detected  (and  perhaps  the  identity  of  the  detector).  In  the 
full  model,  some  filtering  of  this  list  based  on  si2e  would  also  be  appropriate.  For  example, 
brigades  might  keep  track  of  only  battalion-size  enemy  units,  while  divisions  might  track 
only  regimental-size  enemy  units.)  In  any  instance,  we  shall  assume  that  such  a  list  of 
friendly  and  enemy  units  is  available  for  consideration  during  any  forecast. 

Steps  1-2  are  not  properly  part  of  the  actual  GVS  forecast  calculations,  but  must 
nevertheless  be  implemented  before  the  calculations  can  be  done.  The  remaining  steps 
will  then  be  cycled  through  for  each  unit  which  is  being  forecast.  For  our  example,  this 
means  the  brigade  and  its  associated  resolution  units. 

Step  S  -  Compute,  at  the  current  time  step,  the  total  “discounted'1  power  for 

each  resolution  unit  and  the  brigade  headquarters,  using  the  AOI  as  previously 

determined. 

The  actual  mechanics  of  the  computation  of  discounted  power  are  documented  in  previous 
GVS  papers  [11].  This  is  basically  a  distance  (time  and  space)  discounting,  relative  to 
the  blue  force,  which  produces  a  current  point  estimate  of  the  power  of  both  the  red  and 
blue  forces.  We  propose,  at  least  initially,  to  base  the  measure  of  power  for  the  GVS 
curves  on  the  EAGLE  a-unit-eff  attribute,  which  is  computed  on  a  scale  of  0  —  100,  and 
which  represents  the  percentage  of  unit  effectiveness  relative  to  what  if  would  be  at  full 
(TOE)  strength.  The  unit’s  full  strength  firepower  score  would  then  be  multiplied  by 
this  percentage  to  give  the  adjusted  power  (before  time  discounting).  We  would  propose 
that,  at  a  later  time,  more  sophisticated  measures  be  investigated,  e.g.  through  use  of 
a  Required  Manning  Level,  related  to  Radiation,  MOPP,  and  Crews  available,  etc.  (The 
categorical  judgment  methodology  proposed  by  Crawford  [2]  has  several  attractive  features 
with  respect  to  this  issue.) 

This  power  calculation  is,  of  course  only  a  single  point  estimate,  not  a  projection.  How¬ 
ever,  we  believe  the  power  calculated  for  the  Red  resolution  units  provides  a  potentially 
useful  quantitative  basis  for  determining  the  order  of  precedence  in  the  a-prioritized- 
opponents  slot  in  the  res-decision-factors  object  in  the  Characteristics-KB.  Further¬ 
more,  although  we  have  not  yet  fully  developed  the  argument  for  this  assertion,  there  is 
also  a  possibility  that  the  ratio  of  the  overall  Red  and  Blue  GVS  powers  derivable  from  this 
point  estimate  might  also  provide  a  simple,  yet  powerful  basis  for  inferring  the  existence 
of  a  feasible  plan  to  accomplish  a  given  tactical  goal  -  provided  the  time  horizon  within 
which  the  goal  must  be  accomplished  is  within  the  AOI  and  provided  the  size  of  the  AOI  has 
been  correctly  chosen  -  without  having  to  completely  war-game  the  plan  through.  (This 
claim,  were  it  to  prove  out,  would  be  analogous  to  our  earlier  observation  that  in  many 
mathematical  instances  it  can  be  proven  that  a  problem  has  a  solution,  even  though  one 
cannot  produce  that  solution.  However,  as  we  noted,  we  have  not  pursued  this  particular 
line  of  investigation  sufficiently  to  be  certain  of  its  utility.) 

However,  even  if  a  sufficiently  favorable  current  GVS  ratio  were  to  ensure  the  existence 
of  a  feasible  plan,  that  does  not  necessarily  guarantee  any  particular  plan  is  feasible,  only 
that  some  plan  should  be.  Neither  will  a  favorable  GVS  ratio,  in  and  of  itself,  indicate  how 
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feasible  plans  might  be  arrived  at.  Verifying  the  feasibility  of  any  particular  plan  requires 
an  explicit  future-state  prediction,  i.e.,  to  use  the  mathematical  analogy,  substitution  of  the 
candidate  solution  into  the  problem.  The  “brute  force,”  and  clearly  unacceptable  way  to 
do  this  projection  would  be  to  run  the  actual  model,  within  itself,  and  observe  the  results. 
We  believe  that  acceptable  surrogates  for  this  procedure  are  computationally  feasible,  and 
shall  now  describe  one  such  alternative. 

Step  4  -  Begin  the  GVS  projecting  process  using  At  minute  time  increments. 

(We  propose  using  a  At  of  5  minutes  for  resolution  units,  and  possibly  longer  for  higher  level 
command  units.)  We  currently  believe  that  the  most  efficient  vehicle  for  this  projection  will 
be  the  creation  of  temporary  or  “shadow”  objects,  which  have  virtually  identical  structure 
to  the  “real”  resolution  units.  Correctly  done,  this  will  allow  the  use  of  the  inheritance 
structure  of  EAGLE  to  efficiently  pass  any  necessary  attributes.  These  shadow  units  could 
then  be  moved,  attrited,  etc.,  without  the  need  to  make  any  changes  to  the  real  units.  This 
approach  would,  however,  require  careful  purging  at  the  end  of  the  forecast  of  any  reference 
to  these  shadow  objects  from  portions  of  the  model  such  as  the  Terrain  Manager. 

Step  5  -  Check  next  task  for  unit  to  determine  whether  a  transition  from 
the  current  task  is  required. 

This  will  require  reference  to  the  plan  as  stored  in  the  Tactics-KB  to  determine,  based  on 
the  positions  and  powers,  whether  a  change  of  phase/tasks  is  required.  Here  again,  having 
a  shadow  unit  with  pointers  to  all  of  the  attributes,  including  the  phase  transition  rules 
for  that  unit’s  specific  plan,  would  greatly  simplify  this  process. 

As  alluded  to  earlier,  whether  a  new  task  is  implemented  on-order  as  opposed  to  at  a 
particular  point  in  time  can  be  a  crucial  issue.  In  actual  operations,  local  commanders  will 
probably  prefer  that  all  transitions  be  on-own-initiative  (such  as  being  able  to  order  3/5 
to  attack  down  the  appropriate  corridor  depending  on  how  the  “fight  is  going”),  since  this 
retains  maximum  flexibility.  However,  from  higher's  point  of  view  the  attainment  of  Ob¬ 
jective  C  by  1S00  may  be  essential,  subject  to  certain  constraints  on  losses  by  subordinates. 
The  EAGLE  structure  (and  certainly  GVS  planning)  must  be  responsive  to  both.  As  noted 
above,  we  propose  to  initially  use  the  default  rules,  modified  as  necessary,  to  determine 
whether  an  on-order  phase  change  will  fire.  At  the  same  time,  we  will  also  impose  a  time 
constraint  on  attainment  of  the  final  objective,  i.e.  it  must  be  forecast  to  occur  before  the 
end  of  the  planning  horizon,  thus  perhaps  “forcing”  (or  determining  as  infeasible)  some 
tasks  which  may  exist  for  the  unit.  It  has  been  suggested  that  the  EAGLE  construct  of  the 
Abstract  Higher  Level  may  be  used  as  the  “referee”  between  time  and  event  driven  tactics. 
Correct  resolution  of  forecasted  phase  changes  is  a  critical  area.  Also  a  consideration  here 
is  the  slack  time  issue  which  we  have  previously  commented  on. 

Step  6  -  For  resolution  units  in  contact,  project  the  attrition  during  the 
upcoming  time  step. 
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Note  that  determining  whether  a  phase  change  occurs  at  the  start  of  this  interval  must 
precede  this  step,  since  lh"  attrition  will  relate  directly  to  the  task  to  be  performed  during 
the  upcoming  interval.  Determining  which  units  are  in  contact  can  be  done  very  straight¬ 
forwardly.  e.g.  by  a  simple  geometric  distance  calculation  between  centers  of  mass.  Once 
this  is  determined,  we  propose  to  project  the  attrition  using  the  simple,  range-dependent, 
homogeneous,  square  law  difference  equation  counterpart  of: 


dx  (  R  y> 

s  =  -ay\x~Ri. :) 

*  r 

dt  \  Rmai  / 


where 

a  =  casualties/y-firer-time 

b  —  casualties/x-firer-time 

R  —  range  between  firer  centroids 

Rmaz  —  closest  range  at  which  no  attrition  is  possible 

yz  =  shaping  parameter  for  attacker  (x) 

fiy  —  shaping  parameter  for  defender  (y) 


(The  shaping  parameter  relates  to  the  types  of  weapons  in  the  firing  force  and  is  well 
documented  by  Bonder  and  Farrell.)  This  surrogate  for  the  detailed  attrition  process 
in  EAGLE  is  very  representative  of  how  a  planner  would  war-game  alternatives  in  an 
aggregate  sense.  At  the  completion  of  this  step,  an  estimate  of  the  attrition,  based  on 
location  at  the  start  of  the  time  interval  has  been  made.  This  calculation  is  necessary  not 
only  to  be  able  to  compute  powers  at  the  next  step,  but  also  to  be  able  to  use  existing 
EAGLE  logic  for  movement.  If  the  shadow  unit  object  implementation  is  used,  this  newly 
computed  value  of  a-unit-efF  can  be  stored  in  the  same  named  slot  as  used  by  the  real 
unit. 


Step  7  -  Forecast  a  new  route  if  the  unit  has  not  reached  its  final  objective, 
has  no  additional  routes  stored,  and  the  end  of  the  planning  horizon  has  not  yet 
been  reached. 

This  step,  in  addition  to  the  move  step  described  below,  raises  the  issue  of  how  much  of 
the  existing  EAGLE  code  to  use.  If  a  new  route  is  determined  in  the  forecast  using  C2- 
processes  (which  sets  indices  for  the  movement  rules)  then  extreme  care  must  be  taken  to 
restore  the  data  before  exiting  from  the  shadow  objects.  Our  current  inclination  is  to  use 
the  EAGLE  move  rules  algorithms  for  the  movement  forecast,  whereas  we  ^  not  prnpo-t> 
using  the  EAGLE  code  for  the  attrition  forecast. 

Step  8  -  Move  the  units  for  one  time  step  along,  the  network  of  routes, 
toward  their  next  objective. 
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The  rate  of  movement  will  be  based  on  the  matrix  of  speeds  for  each  operational  activity 
for  GO.  SLOW  GO.  NO  GO  terrain  which  is  available  in  the  KB.  The  raw  speed  inputs, 
modified  by  the  attrition  speed  degradation  factors  as  used  in  the  resolve-attrition-event 
in  EAGLE,  will  be  used.  This  is  essential  in  order  not  to  inflate  movement  rates  in  the 
forecast . 


Step  9  -  Return  to  Step  5  unless  the  planning  horizon  time  has  been  reached. 


Step  10  -  When  the  planning  horizon  has  been  reached,  invoke  the  rules  of 

feasibility. 

These  rules  will  be  based  on  mathematical  relationships  between  the  RED  and  BLUE 
curves  generated.  (In  the  VIC  test  we  used  the  very  simple  criterion  of  did  the  at¬ 
tacker/defender  power  ratio  exceed  3:1  or  not.  The  determination  of  the  exact  rules  to  use 
here  is  really  another  research  issue  in  itself.)  The  fundamental  question  which  this  step 
answers  is  ‘'will  my  current  plan  remain  feasible  out  to  the  planning  horizon?"  If  the  answer 
to  this  question  is  yes.  then  the  GVS  routine  would  return  control  to  the  EAGLE  execution 
model  to  proceed.  Otherwise,  alternative  courses  of  action  would  need  to  be  developed  and 
evaluated  (again  using  future-state  prediction).  Developing  alternative  courses  of  action 
is  not  trivial,  and  invo  lves  issues  well  beyond  the  scope  of  this  report  (some  of  which  were 
addressed,  at  least  generally,  in  [11]  and  [12]).  However,  we  would  expect  that  if  any  con¬ 
tingency  missions  exist  in  the  Scenario-KB,  then  the  first  step  here  would  be  to  conduct 
explicit  future-state  predictions  for  the  n.  Then,  if  none  of  the  contingency  missions  could 
restore  feasibility,  then,  a  noted  above,  we  would  either  have  to  generate  a  feasible  course 
of  action  “on  the  fly"  -  a  much  more  difficult  problem  than  proving  feasibility  of  an  already 
developed  course  -  or  stop  the  model  for  human  intervention.  A  abbreviated  set  of  sample 
calculations,  using  the  steps  described  above  and  keyed  to  our  scenario,  is  contained  in 
Appendix  1. 

We  would  observe  that  this  proposal,  because  it  would  utilize  much  of  the  existing 
EAGLE  code,  would  probably  be  fairly  straightforward  to  implement.  On  the  other  hand, 
because  it  utilizes  EAGLE  code  for  essentially  all  but  the  attrition  forecast,  it  might  turn 
out  to  be  closer  to  the  earlier  discussed  (and  not  particularly  attractive)  recursive  calling  of 
the  model  by  itself.  An  alternative  would  be  the  TDN  forecasting  investigated  by  Manzo 
and  Hughes  [8].  This  would  allow  for  the  use  of  very  simple  heuristics  (e.g.  those  found  in 
manuals  such  as  [14])  along  each  of  the  arcs,  and  probably  greatly  reduce  the  computation 
required  -  at  the  cost  of  a  more  complicated  data  structure  and  longer  development  time. 

VI.  Summary  and  Conclusions 

In  this  report,  we  have  outlined  a  proposed  future-state  decisionmaking  architecture 
for  the  EAGLE  combat  model.  We  have  not  actually  implemented  this  proposed  archi¬ 
tecture.  however  its  implementation  should  be  fairly  straightforward  because  the  design 
utilizes  a  significant  amount  of  existing  code.  Implementing  this  architecture  would  enable 
the  model  to  determine,  ahead  of  time,  when  given  tactical  plans  were  no  longer  feasible. 
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so  that  appropriate  alternative  plans  could  be  either  developed  or  implemented.  The  pro¬ 
posal  may  be  computationally  intensive,  and  therefore  an  alternative  architecture  is  also 
proposed,  although  implementing  this  alternative  architecture  would  require  significantly 
greater  programming  effort. 

In  any  event,  if  the  EAGLE  model  is  to  avoid  what  we  believe  to  be  the  fundamental 
pitfall  of  all  current  systemic  combat  models  -  present-state  decisionmaking  -  our  proposal, 
or  some  variant  of  it,  will  need  to  be  incorporated  into  EAGLE. 


References 

1.  G.  M.  Clark,  “The  Combat  Analysis  Model,”  Ph.  D.  Dissertation,  The  Ohio  State 
L'niversity,  1969 

2.  P.  M.  Crawford,  “Dynamic  Study  of  Factors  Inpacting  on  Combat  Power,”  M.  S.  The¬ 
sis.  Naval  Postgraduate  School,  Monterey,  CA,  March  19SS 

3.  T.  N.  Dupuy,  Numbers,  Prediction  and  War,  Bobbs-Merrill  Publishing,  1979 

4.  J.  K.  Hartman,  S.  H.  Parry,  A.  L.  Schoenstadt,  “Airland  Research  Model."  paper 
presented  to  52nd  MORS  meeting.  Naval  Postgraduate  School.  Monterey,  California. 
June  19S4 

5.  R.  A.  Kilmer,  “The  Generalized  Value  System  and  Future  State  Decisionmaking.” 
M.  S.  Thesis,  Naval  Postgraduate  School.  Monterey.  CA,  March  19S6 

6.  T.  Karchmann,  The  Common  Lisp  Companion.  John  Wiley  and  Sons,  draft  copy. 
1990 

7.  G.  F.  Lindsay.  “Constructing  Interval  Scales  from  Categorical  Judgement.”  Naval 
Postgraduate  School,  Monterey,  CA  (unpublished  paper) 

S.  J.  J.  Manzo,  J.  M.  Hughes,  “A  Surrogate  for  Soviet  Division  Level  Automated  Troop 
Control  System,”  M.  S.  Thesis,  Naval  Postgraduate  School,  Monterey,  CA.  June  19S4 

9.  S.  H.  Parry,  A.  L.  Schoenstadt.  “The  Airland  Wargame,”  presentation  to  NPS/C'EMA 
Conference  on  Combat  Modeling.  May.  19S5 

10.  A.  L.  Schoenstadt  and  S.  H.  Parry,  "Toward  an  Axiomatic  Value  System,"  Naval 
Postgradute  School  Technical  Report  NPS  53-86-008,  May  1986.  26  pp. 

11.  A.  L.  Schoenstadt  and  S.  H.  Parry,  “Future-State  Decisionmaking  Under  the  General¬ 
ized  Value  System  Architecture,”  Naval  Postgradute  School  Technical  Report  NPS  53- 
89-013,  July  1989,  27  pp. 

12.  “Demonstration  of  the  Generalized  Value  System  in  the  Vector-in- Commander  (VIC) 
Model,”  Rolands  and  Associates,  Monterey,  CA,  June  1987  (unpublished  report) 

13.  “Preliminary  Conceptual  Design  for  the  Airland  Research  Model,”  Rolands  and  As¬ 
sociates  Corp.,  Monterey,  CA,  1986  (unpublished  paper) 

14.  Staff  Officer's  Field  Manual  -  Organizational,  Technical  and  Logistic  Data  (Unclassi¬ 
fied  Data),  Field  Manual  FM  101-10-1,  Volumes  1  and  2,  Headquarters,  Department 
of  the  Army,  October  1987 

15.  Staff  Organization  and  Operations.  Field  Manual  FM  101-5,  Headquarters,  Depart¬ 
ment  of  the  Army,  May  1984 

10.  The  Command  Estimate,  Student  Text  100-9.  U  S.  Army  Command  and  General  Staff 
College.  Fort  Leavenworth,  KS,  July  1987 

17.  “EAGLE  1.0  -  Preliminary  Design,"  U.  S.  Army  TRADOC  Analysis  Center.  Fort 
Leavenworth,  I\S,  19S9  (working  papers) 


IS 


IS.  “The  JANUS  Combat  Model,”  U.  S.  Army  TRADOC  Analysis  Center,  White  Sands 
Missile  Range,  NM,  19S1 

19.  "The  Vector-in-Commander  Model."  U.  S.  Army  TRADOC  Analysis  Center,  White 
Sands  Missile  Range,  NM,  19S6 


Appendix  1  -  Sample  GVS  Calculations 

This  appendix  presents  sample  calculations  of  the  Generalized  Value  System  forecast 
of  the  power  of  the  brigade-level  task  force  shown  in  Figure  A-l.  (This  is  the  same  scenario 
described  in  the  body  of  the  report,  with  coordinate  locations  added.  The  coordinates  are 
in  kilometers  relative  to  an  origin  in  the  lower-left  corner  of  the  map.)  The  example  is 
presented  as  a  series  of  tables  for  each  of  three  options  described  below.  Each  series  of 
tables  describes  the  status  (power)  of  Blue  and  Red,  starting  at  the  current  time  and 
forecasting  to  the  end  of  the  plan  represented  by  that  option  (or  to  infeasibility). 

As  described  in  the  report,  an  exponential  discounting  factor  is  applied  to  each  unit, 
based  on  the  expected  time  until  that  unit  is  in  position  to  exert  its  power  by  (in  this  case  ) 
direct  fire.  This  discounting  is  reflected  in  column  6  of  the  tables.  The  power  of  each  unit 
in  contact  is  also  reduced  based  on  attrition  losses.  Column  4  in  the  tables  reflects  these 
losses.  Finally,  we  use  as  the  measure  of  feasibility  for  the  Blue  plan  that  the  ratio  of  Blue 
to  Red  power  must  exceed  two. 

As  not?d  above,  there  is  one  series  of  tables  for  each  of  three  options: 

Option  1  assumes  that  neither  Red  unit  (4th  Tank  Battalion  or  51st  Tank  Regiment) 
moves  to  counter  Blue.  In  this  case,  the  power  ratio  always  exceeds  the  threshold  and 
therefore  Blue  should  be  able  to  reach  Objective  C  by  time  100. 

Option  2  assumes  that  the  4th  Tank  Battalion  moves  to  counterattack  Blue  TF  3/5 
at  the  road  junction  located  at  (16.6).  In  this  case,  the  power  ratio  falls  below  the  threshold 
at  time  90.  which  indicates  that,  unless  Blue  were  to  take  further  action,  he  may  not  be 
able  to  accomplish  the  mission  of  taking  Objective  C. 

Option  3  assumes  that  the  4th  Tank  Battalion  moves  to  counterattack  Blue  TF  3/5 
at  the  road  junction  located  at  (16,6),  but  that  Blue  counters  by  committing  the  Attack 
Helicopters,  at  time  80.  so  that  they  can  attack  by  time  90,  i.e.  before  the  counterattack 
hits  TF  3/5.  This  restores  the  feasibility  ratio,  and  indicates  that  Blue  has  sufficient 
power  to  handle  this  contingence.  More  importantly,  and  this  is  a  very  important  aspect 
of  future-state  prediction,  not  only  does  this  calculation  show  that  this  alternative  will 
restore  feasibility,  but  it  also  indicates  WHEN  to  alternative  needs  to  be  implemented.  In 
this  instance,  the  calculations  indicate  there  is  no  need  to  act  at  the  current  time,  since 
the  power  ratios  are  still  feasible  60  minutes  from  now,  and  the  alternative  plan  does  not 
need  to  be  implemented  until  after  that  time. 
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585 

6 

Amount  of 
power 
discounted 
for "not  in 
pos." 

O 

O 

s 

Sc 

S 

285 

5 

Current 
power  if  unit 
is  "in  pos." 

(1  minus  4) 

240 

200 

450 

550 

250 

700 

4 

Total  power 
lost  due  to 
attrition 

091 

200 

o 

o 

o 

o 

3 

Estimated 
time  until 
'"in  post." 

o 

O 

15  min. 

10  min. 

15  min. 

45  min. 

2 

Location 

00 

<N 

<NI 

(10,6) 

ON 

cn 

(16,10) 

(17,20) 

1 

Full 

Strength 
Power  (in 

pos." 

400 

400 

450 

550 

250 

700 

Unit 

TF 1/92 

TF  3/80 

TF3/5 

Hclos 

Total  Blue 

St 

1 

C 

£ 

os 

2 

'c 

£ 

OS 

2 

% 

£ 

£ 

In 

St 

si 

£ 

os 

2 

Total  Red 
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Full  Current  power 

Strength  Estimated  Total  power  power  if  unit  discounted  Current 

Power  (in  time  until  lost  due  to  is  "in  pos."  for  "not  in  power 


Full  Current  power 

Strength  Estimated  Total  power  power  if  unit  discounted  Current 
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TIME— 30  OPTION 


Notes 

1320/515=2.56 

Blue  OK 

7 

Current 
power 
(5  minus  6) 

310 

270 

270 

470 

1320 

o 

(N 

i— • 

£ 

150 

155 

515 

6 

Amount  of 
power 
discounted 
for "not  in 

_  _  tr 

pos. 

O 

o 

180 

£ 

o 

O 

a 

T— « 

545 

5 

Current 
power  if  unit 
is  "in  pos." 

(1  minus  4) 

310 

/— s 

£ 

450 

550 

120 

£ 

a 

nj 

5 

4 

Total  power 
lost  due  to 
attrition 

£ 

130 

O 

o 

SB 

O 

o 

c: 

3 

Estimated 
time  until 
'"in  post." 

O 

o 

30  min. 

10  min. 

o 

o 

1 

o 

co 

90  min. 

2 

Location 

00 

o 

e-« 

(SOI) 

(3,9) 

So 

(S' ID 

(16,10) 

(17,20) 

1 

Full 

Strength 
Power  (in 

pos." 

400 

P 

450 

550 

200 

200 

250 

700 

Unit 

rj 

TF3/80 

TF3/5 

Helos 

Total  Blue 

St 

1 

c 

£ 

DS 

2 

<N 

1 

« 

C£ 

2 

rf 

% 

e- 

s 

H 

In 

at 

6£ 

£/ 

ec 

ec 

2 

Total  Red 
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TIME— 75  OPTION 


Notes 

Not  committed 

Initiates  move  to  CA 
at  Rd  junction 

— 

in 

cvi 

l) 

in  w 
in  O 

s  s 

—  E 

7 

Current 
power 
(5  minus  6) 

240 

200 

350 

470 

1260 

170 

IT) 

585 

_ 

6 

Amount  of 
power 
discounted 
for  "not  in 
pos." 

O 

o 

£ 

r~* 

s 

ss 

285 

1 

5 

Current 
power  if  unit 
is  "in  pos." 

(1  minus  4) 

240 

s 

CN 

450 

550 

g 

1 

1 

4 

Total  power 
lost  due  to 
attrition 

3 

200 

o 

o 

o 

o 

3 

Estimated 
time  until 
'"in  post." 

O 

O 

15  min. 

10  min. 

15  min. 

45  min. 

1 

2 

Location 

(12,8) 

“X 

r-* 

(10,6) 

(3,9) 

(16,10) 

(17,20) 

1 

1 

Full 

Strength 
Power  (in 

pos." 

400 

400 

450 

550 

250 

700 

1 

Unit 

TF 1/92 

TF  3/80 

TF  3/5 

Helos 

Total  Blue 

1— ■ 

1 

£ 

& 

2 

(N 

1 

C 

S 

0£ 

2 

TK  Btn  #4 

I 

Total  Red 
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Current  power 

Estimated  Total  power  power  if  unit  discounted  Current 


35 


Distribution  List 


No. 
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2.  Superintendent 

ATTN:  Library,  Code  0142 
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Monterey,  California  93943-5002 

3.  Professor  Arthur  L.  Schoenstadt 
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10 
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1 

1 

1 
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